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TECHNICAL  PROBLEM 


As  the  cost  of  computer  hardware  continues  to  fall,  more  and  more 
ambitious  software  applications  are  conceived.  The  conversion  of  the 
ambitious  conceptions  into  complete  and  reliable  final  products,  on  budget  and 
within  schedule,  continues  to  be  an  elusive  goal  for  the  majority  of  projects. 
Much  emphasis  is  being  placed  on  solving  this  problem  with  tools  and  tech¬ 
niques  that  are  applicable  throughout  the  software  life  cycle.  Following  is  a 
partial  list  of  the  approaches  currently  being  actively  pursued.  ^  / •  / 

1.  Automated  tools  for  program  analysis  and  testing  -  this  is  the 
approach  which  best  describes  CAVS . 

2.  Fourth  generation  languages  -  usually  described  as  non-procedural 
languages.  The  biggest  impact  so  far  has  been  in  data  base 
applications  (as  a  more  productive  replacement  "or  COBOL). 

3.  Software  management  and  configuration  control  tuol3  -  a  must  for 
large  software  developments. 

4.  Software  support  systems /programming  environment  tools  -  easy  to 
use,  integrated  environments.  The  best  known  examples  are  UNIX, 
INTERLISP,  SMALLTALK. 

5.  Tools  for  writing  and  analyzing  requirements/design  specifications 
-  the  earlier  an  error  is  detected  the  less  it  costs  to  fix  it. 

6.  Programming  workstations  -  the  next  step  after  timesharing  - 
eliminating  bottlenecks  due  to  saturation  of  timesharing  systems. 
The  falling  cost  and  rising  performance  of  microcomputer  systems 
is  making  it  economically  feasible  to  provide  software  developers 
with  dedicated  workstations  which  can  be  networked  together  for 
large  software  development  projects. 

7.  Software  engineering  life  cycle  support  systems  -  putting  all  the 
pieces  together  in  an  easy  to  use,  integrated  framework  for  all 
phases  and  all  personnel  during  the  entire  software  life  cycle. 


This  project  falls  in  the  first  area,  automated  tools  for  program 
analysis  and  testing.  The  objective  was  to  design  and  implement  a  tool  for 
analyzing  and  testing  COBOL  source  programs.  The  tool,  called  CAVS,  for  COBOL 
Automated  Verification  System,  is  a  prototype  of  a  software  tool  to  improve 
the  reliability  and  maintainability  of  COBOL  software  systems.  CAVS  can  be 
applied  during  the  testing,  verification,  validation,  and  error  detection/ 
correction  phases  of  software  development. 
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2  GENERAL  METHODOLOGY 

This  effort  was  accomplished  in  two  phases.  Phase  I  consisted  of  a 
study  of  the  COBOL  programming  language  and  of  the  latest  automated 
software  test  and  verification  tools,  to  insure  that  the  most  advanced  tech¬ 
niques  and  capabilities  would  be  included  in  this  development.  The  output  of 

Phase  I  was  a  CAVS  Initial  Design.  A  Functional  Description,^  System/ 

2  3 

Subsystem  Specification,  and  Final  Report  were  produced  during  Phase  I. 

Phase  II  consisted  of  the  detailed  design,  implementation,  and  testing 
of  CAVS  on  the  VAX  11 /780/VMS  computer  system  at  General  Research  Corporation, 
Santa  Barbara,  California.  CAVS  was  then  installed  on  the  VAX  11 /780/VMS  and 
Honeywell  H6180/GC0S  computer  systems  at  the  Rome  Air  Development  Center 
(RADC) ,  Griffiss  AFB ,  N.Y.  It  was  also  installed  on  the  UNIVAC  1100/EXEC  8 
computer  systems  at  the  Defense  Mapping  Agency  (DMA)  Hydrographic/Topographic 
Center  (DMAHTC)  in  Washington,  D.C.,  at  the  DMA  Aerospace  Center  (DMAAC)  in 
St.  Louis,  Mo.,  and  at  the  Navy  Data  Automation  Facility  (NAVDAF)  in  Newport, 
Rhode  Island. 


After  installations  were  completed,  user  training  courses  were  conducted 
at  the  two  DMA  sites.  A  maintenance  training  course  was  conducted  at  DMAHTC. 
Two  important  documents  from  Phase  II  were  the  User's  Manual  and  the  Program 
Maintenance  Manual.’’ 


M.  Sharp,  et  al.,  COBOL  Automated  Verification  System  Functional  Descrip¬ 
tion,  General  Research  Corporation  CR-2-970,  November  1980. 

R.  Melton,  et  al.,  COBOL  Automated  Verification  System: System/Sub- 
System  Specification,  General  Research  Corporation  CR-1-970,  November  1980. 

G.  Greenberg,  et  al.,  COBOL  Automated  Verification  System  Final  Report: 
Study  Phase,  General  Research  Corporation  CR-3-970,  November  1980. 

R.  Melton,  et  al.,  COBOL  Automated  Verification  System  User's  Manual, 
General  Research  Corporation  CR-4-970/R1,  August  1983. 

R.  Melton,  et  al.,  COBOL  Automated  Verification  System  Program  Maintenance 
Manual ,  General  Research  Corporation,  CR-7-970/R1 ,  July  1983.  ” 
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3  TECHNICAL  RESULTS 

A  prototype  AVS  for  COBOL  was  produced  as  a  result  of  the  project.  CAVS 
is  an  Integrated  set  of  tools  that  builds  a  database  from  COBOL  source,  and 
then  accesses  the  database  for  documenting,  analyzing,  and  testing  COBOL 
programs.  CAVS  processes  six  dialects  of  COBOL:  ANSI  Standard  1968  and  1974, 
UNIVAC  FIELDATA,  UNIVAC  ASCII,  Honeywell  60/6000,  and  Honeywell  COBOL-74. 

CAVS  is  currently  installed  on  a  VAX  11/780  under  VMS,  on  a  UNIVAC  1100/60 
under  EXEC  8,  and  on  the  Honeywell  6180  under  GCOS. 

The  principal  functions  performed  by  CAVS  are: 

•  Static  Analysis,  in  which  multi-module  checking  is  performed  for 
errors  and  dangerous  coding  practices  not  normally  detected  by 
COBOL  compilers. 

•  Instrumentation,  which  consists  of  automatic  insertion  into  a 
COBOL  program  of  calls  to  data  collection  routines  that  record 
data  about  program  operations  and  paths  taken  during  execution. 

•  Trace  File  Analysis,  which  combines  the  program  information  from 
the  CAVS  database  with  the  trace  file  information  created  by 
running  an  instrumented  program  to  produce  performance  reports 
about  the  program's  dynamic  operation. 

•  Documentation,  which  generates  a  number  of  reports  from  the  CAVS 
database  about  a  program's  structure  and  usage  of  variables. 

These  reports  are  of  use  to  developers,  testers,  and  maintainers. 

•  Precompilation  of  a  COBOL  language  extension  that  includes  "end 
verb"  statements  (similar  to  the  suggested  COBOL  8x  syntax)  into 
standard  COBOL. 

•  Reformatting  of  COBOL  source  code  with  indentation  of  nested  IF 
verbs  and  standardized  spacing  of  the  clauses  of  other  verbs  for 
improved  readability. 


! 

V 


PHECSBZMO  MOB  MaMK-MOT  FILMS 


1 


5 


Features  of  CAVS  include: 

•  Interactive  operation  with  menus,  help  screens,  menu  commands, 
wildcards  in  name  selection,  filename  prompts,  selective  reports 

•  Batch  operation  with  commands  for  processing  large  amounts  of 
source  code,  and  generating  comprehensive  reports 

•  Automatically  updated  library  of  COBOL  source  code,  reports  about 
it,  and  testing  history 

•  Efficiency  to  support  frequent  use  on  medium  to  large  COBOL 
systems 

•  Applicable  to  systems  of  up  to  250,000  lines  of  COBOL  source 

Interactive  Mode 

CAVS  provides  menus  that  tell  the  user  which  functions  and  reports  are 
available.  For  novice  users,  one  or  more  help  screens  a. a  available  from  each 
CAVS  menu.  Experienced  CAVS  users  can  suppress  the  display  of  CAVS  menus  by 
entering  sequences  of  menu  selections.  Frequently  used  sequences  of  menu 
selections  can  be  named  and  saved  as  commands.  Wildcards  provide  a  convenient 
way  of  selecting  specific  names  (program- IDs ,  data  items,  literals,  para¬ 
graphs,  files/records,  copy  members/records,  and  global  records),  as  well  as 
finding  all  names  available.  Filename  prompts  provide  flexibility  in  reading 
in  COBOL  source  elements,  generating  concise  reports,  and  outputting  COBOL 
source  elements.  Viewing  reports  interactively  before  sending  them  to  a 
report  file  allows  very  selective  reports  to  be  generated. 

Figure  3.1  gives  a  broad  overview  of  the  CAVS  functions  in  terms  of  the 
menus  that  the  user  interacts  with  to  control  the  functions.  The  chart  is 
arranged  in  hierarchical  order  by  the  connectivity  from  one  menu  to  another. 
The  WELCOME  menu  controls  initialization ,  the  FUNCTIONS  menu  controls  access 
to  the  main  function  menus,  and  the  END  OF  CAVS  controls  the  session  wrapup. 
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Menu  Hierarchy 


Batch  Mode 

Batch  mode  is  provided  for  processing  large  source  elements,  or  gener¬ 
ating  comprehensive  reports  for  baseline,  archival  documentation.  Batch 
commands  make  it  easy  to  direct  CAVS  in  batch  mode  because  they  relate 
directly  to  the  CAVS  output  desired  rather  than  the  sequence  of  processing 
CAVS  goes  through  to  produce  the  output.  The  CAVS  batch  commands  are  listed 
below: 


[ PROJ [ ECT  LIBRARY].] 
IEXPA[ND] .] 

[CHANfGE] .] 


{OPTI[ON]  =  option  {.option}.} 

where  option  is  one  of 


ABOR[T] 
CHEC[K  OUT] 
DOCU[MENT] 
ERRO [  RS  ] 
INSTRUMENT] 
IOCO{UNTS] 


LIST 

PREC[OMPILE] 
REAC[HING  SET] 
REFOtRMAT] 
SUMM[ ARY] 
TIMIlNG] 


{REPO{RT]  =  report  {.report}.} 
where  report  is  one  of : 

CALLfS] 

GLOB[ AL  VARIABLES] 

PROF[ ILE] 

GLOB[AL  VARIABLES] /E[NHANCED] 
10 

PROP  [  ERTIES  ] 

CROSfS] 

CALL[S]/T[EXT] 

BAND] S/<n>] 

PICT[URE] 


SUMMARY 

BRANCHES 

STATEMENTS 

TRACE 

TIME 


{FOR  P [ ROGRAM-IDS ]  -  <namel><name2> . . . 

{TEST[ CASE]  -  <name> 

{REACHING  SET] , PROG] RAM-ID  -  «name>), 

TO  “  <statement  number> , 

FROM  -  <8tatement  number>,} 

[  ]  optional 

{  }  optional  an  arbitrary  number  of  times 
<  >  integer  constant  or  character  string 


l 
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Support  for  Structured  Programming  In  COBOL 

CAVS  supports  structured  programming  in  COBOL  In  a  number  of  ways. 

COBOL  constructs  (data  division  and  procedure  division)  are  automatically 
Indented  on  all  hard  copy  source  listings.  Source  listings  also  include  a 
perform  range  cross  reference  at  the  end  of  each  PROGRAM-ID.  CAVS  also 
provides  the  option  to  automatically  reformat  COBOL  source  text  to  make  it 
easier  to  read  (including  indentation  of  procedure  division  constructs). 
Structured  COBOL  written  in  an  extension  Do  COBOL  is  recognized  by  CAVS  and 
can  be  automatically  precompiled  into  standard  COBOL.  The  major  support  for 
structured  programming  in  COBOL  is  the  CAVS  structured  walkthrough.  This  is 
an  innovation  in  CAVS  which  allows  you  to  follow  the  source  code  of  very  large 
programs  at  a  video  terminal,  using  the  program  structure  as  the  guide  to 
examining  the  code.  Top  levels  of  the  structure  are  displayed  first,  and  with 
simple  commands  you  can  expand  to  successively  lower  levels,  and  then  easily 
return  to  where  you  started. 


1 

(HOD >214 

IDENTIFICATION  DIVISION. 

130 

(NOP1273 

130 

(flOP  >274 

000-NA IN-PARAGRAPH  . 

131 

(NOP >2 75 

N0VE  0  TO  IFLA0  . 

132 

(NODI274 

HULTIPLY  1  FT  -1  GIV1N0  ANSWER  . 

133 

(NOP  1277 

PERFORN  GRC-L00P - 5  UNTIL  NOT 

134 

(NOP  1278 

GO  TO  EXIT-PROG  . 

135 

(NOP >279 

READKT-ERR0P-R0UTINE  . 

134 

(NOD  1280 

ADD  1  TO  IFLAG  . 

137 

( NOP ) 28 l 

IF  IFLAG  =  1 

(  <  linn  to  expand 

Ml 

(NOP 1284 

ELSE 

M2 

(NOD  1287 

IF  IFLAG  =  2 

(  8  lines  to  exeand 

M9 

(NOD >294 

ELSE 

(  7  lines  to  e/eand  ! 

154 

(NOD  1304 

EXIT-PROO  , 

157 

(NOD  1305 

EXIT  PR0GRAH  . 

1 58 

(NOD >304 

158 

(NOD  1307 

158 

(NOD) 308 

GRC-L00P - 5 

\CRV*ne>:t  screeni*»exit.L*librar*  ouersrP*eoe.R=ret<jrn.N>*exeand  ftut  NIL  CP' 


Error/Warning  Reports  (Static  Analysis) 

CAVS  provides  the  following  static  analysis  functions: 

•  Call  checking  to  detect  errors  in  the  number  of  calling  parameters 
or  picture  mismatch  between  parameters. 

•  Symbol  set/use  checking  to  detect  data  items  which  are  used  but 
not  set  or  set  but  not  used. 

•  Data  flaw  analysis  to  detect  data  items  which  are  used  before 
being  set  on  all  paths,  reset  before  being  used,  or  set  and  then 
not  used  on  a  particular  path. 

•  Structure  checking  to  detect  unreachable  code  and  potential 
infinite  loops. 

•  Picture  checking  to  detect  implicit  picture  conversions  in  move 
statements . 


Each  of  these  checks  may  be  turned  on  or  off  from  the  menu. 


1  - 

3  - 

4  - 


3  - 


•SRRORS/UARNINGS - CURRENTLY — 

RIND  ERRORS/ WARNINGS 

SELECT  nODULE(S)  REAiiKY 

NEXT  NODULE 

RESET  CALL  CHECKING  (ON  OR  OFF)  ON 

RESET  GRAPH  CHECKING  (ON  OR  OFF)  ON 

RESET  NODE  CHECKING  ' ON  OR  OFF)  ON 

SELECT  DATAFLOW.  SET/USE  OR  OFF  SET/ USE 

RESET  LIST  OPTION  (FULL  OR  FARTIAL)  PARTIAL 

for  h» i p ) : 


•'.nENU 


Choos*  fro*  »*mi.  ent«r  4  co»««ndi ( 'H' .  'L‘ . 'D' 
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Dynamic  Analysis 

Dynamic  analysis  is  a  three  step  process: 


Automatic  COBOL  source  code  instrumentation  using  CAVS 
Compilation/execution/trace  file  generation 
Trace  file  analysis  using  CAVS 


CAVS  performs  abort  tracing  instrumentation  timing  instrumentation,  I/O 
instrumentation,  and  statement/branch  Instrumentation.  After  executing  the 
instrumented  COBOL  and  generating  a  trace  file,  CAVS  can  be  used  to  produce 
abort  trace  reports,  timing  reports,  or  statement/branch  coverage  reports. 
Statement/branch  coverage  results  can  be  saved  on  the  project  library  and 
accumulated  to  provide  a  testing  history. 

Documentation 

CAVS  provides  a  wide  variety  of  documentation  reports  in  both 
batch  and  interactive  mode.  They  include  detailed  reports  about 
PROGRAM-IDs ,  symbol  properties,  symbol  cross  references,  and  source  text 
reports.  System-wide  reports  are  provided  on  PROGRAM-IDs,  ENTRY  POINTS, 
global  records  (in  COMMONS,  FILES,  or  COPYs),  and  TESTCASES. 

Automatically  Updated  Library 

CAVS  automatically  updates  the  project  library  so  that  it  is  as 
current  as  the  last  source  code  processed.  A  baseline  library  can  be  used  for 
baseline  source  code,  reports,  and  testing  history.  Private  libraries  can  be 
created  and  maintained  economically,  saving  only  changes  to  the  baseline 
library  on  change  files. 


Efficiency  —  What  Does  it  Cost? 

CAVS  processes  source  code  (read  and  create/update  a  project  library)  is 
about  1.5  times  compile  time.  The  CAVS  project  library  is  comparable  to 
source  code  size  (about  the  same  size  as  your  source  code  stored  in  80  column 
card  images).  CAVS  reports  are  easy  to  use,  and  are  often  better  than 
compiler  listings  or  text  editor  searches  for  solving  specific  problems. 
Selective  reports  generated  in  menu  mode  are  especially  cost-effective.  The 
cost  of  CAVS  dynamic  analysis  is  highly  dependent  on  the  logic  of  the  program. 
In  general  it  causes  about  20%  code  expansion  and  50%  CPU  overhead. 


Applicable  to  Large  Software  Systems 

CAVS  is  especially  cost-effective  for  large  software  systems 
consisting  of  many  interrelated  programs  or  subroutines.  It  is  usually 
too  expensive  to  reanalyze  a  whole  system  in  order  to  reanalyze  one  or 
two  modified  subroutines.  The  CAVS  project  library  contains  inter¬ 
relationships  between  all  programs,  subroutine^  files,  and  copy  members 
Modified  subroutines  can  be  reanalyzed  separately,  and  the  entire  library 
automatically  updated  at  the  same  time. 


4  IMPLICATIONS  FOR  FURTHER  RESEARCH 

The  continuing  research  In  source  code  analysis  systems  sponsored  by 
RADC  demonstrates  that  the  concepts  are  largely  independent  of  the  language 
the  source  code  is  written  in.  The  following  comments  are  derived  from 
experience  with  CAVS,  but  the  implications  of  that  experience  for  future 
research  apply  to  any  language. 

Experience  has  shown  that  the  AVS  features  embodied  in  CAVS  are  useful, 
and  in  particular,  that  interactive  operation  combined  with  user  selection  of 
report  scope  leads  to  more  efficient  use  of  an  AVS.  As  a  result  of  using  the 
system,  the  following  statements  can  be  made  that  point  the  way  to  future 
research. 

•  There  is  a  wealth  of  information  in  an  AVS  data  base,  and  more 
could  be  added.  Many  useful  reports  could  be  generated  that  are 
not  now  available  from  existing  or  new  information  in  the  data 
base. 

•  Interactive  users  would  benefit  from  more  modes  of  viewing  the 
reports.  Spreadsheet  calculators  have  shown  the  way  to  concepts 
of  moving  one  or  more  "windows"  over  a  large  report  to  view  or 
alter  the  contents. 

•  Even  more  sophisticated  viewing  techniques  could  be  applied  to 
some  reports  as  has  been  done  in  the  structured  walkthrough.  In 
structured  walkthrough  the  user  can  follow  complex  source  code, 
guided  by  the  code  structure.  CAVS  knows  the  meaning  of  the 
structure  and  makes  it  easy  to  walk  through  it.  Other  reports 
could  use  content  to  guide  the  user,  and  there  are  several  other 
"maps"  that  could  be  used  to  guide  the  source  code  walkthrough. 

•  Demonstration  of  the  utility  of  CAVS  as  an  interactive  tool  leads 
naturally  to  the  idea  of  distributing  the  tool  in  a  "workstation" 
environment.  One  central  data  base  would  be  maintained,  and  users 
at  work  stations  could  retrieve  sections  of  it  to  their  own  work 
station  for  viewing.  Changes  could  be  made  to  the  central  data 
base  as  well,  but  security  measures  would  have  to  be  Introduced. 


•  The  ultimate  goal  of  all  this  research  should  be  the  development 
of  a  "life  cycle"  environment  In  which  the  data  base  starts  with 
the  requirements  definition  and  builds  from  there.  Many  tools 
would  have  access  to  the  data  base,  which  Includes  all  the  history 
of  the  evolution  of  the  code. 

These  broad  areas  are  expanded  In  the  following  sections. 

Section  Topic 

4.1  New  Reports  and  Analyses 

4.2  Enhanced  User  Interface 

4.3  Expanded  Walkthrough  Capability 

4.4  AVS  Tool  Technology  In  a  Life  Cycle  Environment 

4.1  NEW  REPORTS  AND  ANALYSES 

4.1.1  Enhancements  to  Matrix  Reports 

The  matrix  report  summarizes  the  usage  of  global  variables  (rows)  across 
several  modules  (columns).  A  possible  enhancement  would  be  to  use  the  matrix 
display  for  interactively  selecting  a  global  variable  and  a  program-ID  for 
more  detailed  display.  The  user  could  select  a  row/column  element,  a  whole 
row  (one  variable  in  all  modules) ,  or  a  whole  column  (all  global  variables  in 
one  module).  Additional  information  that  could  be  displayed  includes  state¬ 
ment  cross  reference  numbers,  statement  cross  reference  text,  context  report, 
and  a  properties  report.  CAVS  users  at  low-speed  video  terminals  or  hardcopy 
terminals  would  get  large  matrices  split  across  several  screens  as  they 
currently  do.  An  interactive  user  at  a  high-speed  video  terminal  could  scroll 
horizontally  (across  modules)  or  vertically  (across  global  variables)  to  view 
a  matrix  larger  than  one  screen. 

Note  that  this  approach  can  be  applied  to  a  variety  of  matrix  reports  - 
symbol  used/symbol  set,  calling  module/called  module,  testcase/module ,  copy 
text/module,  file/module.  The  wildcard  idea  could  be  used  to  build  the  matrix 


according  to  the  user's  needs  (row  names  of  interest /column  names  of  interest) 
thus  providing  a  natural  way  to  limit  the  amount  of  Information  presented. 


4.1.2  Dynamic  Analysis  Enhancements 

Statement  coverage  and  hit/not-hit  reports  could  be  done  in  the 
same  fashion  as  the  structured  walkthrough.  For  a  coverage  report ,  the 
statement  execution  counts  would  appear  on  the  lefthand  side.  For  hit /not  hit 
reports,  a  yes/no  indicator  would  appear  on  the  lefthand  side.  With  suitable 
video  terminals,  statements  not  executed  could  be  displayed  in  brighter 
intensity  or  reverse  video,  or  even  in  a  different  color  (red  for  instance). 

While  a  trace  file  is  being  read,  video  terminal  users  could  be  pre¬ 
sented  with  a  display  of  the  dynamic  calling  tree,  down  to  the  perform 
range/block  level.  This  applies  to  both  abort  trace  fileB  and  coverage  trace 
files.  The  source  code  of  the  program  that  was  executed  as  the  trace  file  was 
created  could  also  be  displayed  (see  the  discussion  of  TRACE  WALKTHROUGH/ 
WALKBACK  in  Sec.  4.3.2). 


A  method  of  coverage  instrumentation/analysis  which  reduces  the  size  of 
CAVS  trace  files  by  a  factor  of  20  to  100  was  designed  and  partially  imple¬ 
mented  during  Phase  II  of  the  CAVS  project.  This  implementation  will  have  to 
be  completed  before  CAVS  can  be  effectively  used  in  coverage  testing  of  large 
COBOL  systems . 

Programs  that  nearly  fill  memory  may  become  too  large  to  run  when  the 
entire  program  is  instrumented.  One  approach  to  this  problem  is  to  add  a 
means  of  merging  the  trace  files  produced  by  the  instrumented  code.  The 
program  could  then  be  run  (with  the  same  data) ,  in  several  versions  with 
different  portions  instrumented,  and  then  the  trace  files  merged.  In  this 
way,  comprehensive  test  reports  can  be  obtained  for  any  size  of  system.  The 
merge  capability  would  be  an  enhancement  to  the  current  CAVS  dynamic  analysis 
capabilities . 


A  new  standard  for  COBOL  (COBOL/80x)  has  been  proposed  and  is  slowly 
being  accepted  by  the  COBOL  community.  It  includes  a  major  extension  to  the 
structured  control  constructs  of  COBOL.  CAVS  can  contribute  to  a  smooth 
transition  to  the  new  standard  by  precompiling  the  new  structured  constructs 
into  today's  standard  COBOL.  New  COBOL  code  could  be  written  with  the  new 
constructs,  and  old  code  could  be  revised  to  use  the  new  constructs,  before 
upgraded  COBOL  compilers  are  available. 

A  noteworthy  trend  in  newer  programming  languages  is  the  inclusion  of 
executable  assertions.  The  same  thing  can  be  accomplished  for  existing 
languages  by  precompiling  assertions  into  standard  code.  The  CAVS  COBOL 
precompiler  could  be  enhanced  to  support  executable  assertions  for  COBOL.  A 
further  enhancement  to  CAVS  would  tie  assertion  violations  to  the  trace  file 
created  by  an  instrumented  COBOL  program.  Dynamic  testing  reports  would  then 
be  able  to  trace  the  path  to  an  assertion  violation  (under  the  kinds  of 
interactive  user  control  described  in  Sec.  A. 3. 2  -  TRACE  WALKTHROUGH/ 

WALKBACK) . 

4.1.3  Module  Documentation  Enhancements 

The  module  documentation  report  has  proven  useful  in  self-documenting 
CAVS,  PAVS,  and  J73AVS.  CAVS  now  provides  this  as  an  on-line  report,  which  is 
as  up-to-date  as  the  project  library  from  which  it  is  generated.  But  it  can 
be  more  effectively  used  in  interactive  mode  if  it  becomes  the  top  of  a  set  of 
reports  (XREF,  TEXT,  and  CONTEXT)  which  the  user  can  request  as  he  needs  to: 

1.  For  a  specified  formal  parameter. 

2.  For  a  specified  common  variable. 

3.  For  each  external  called  or  each  calling  routine. 

4.  For  a  specified  file  in  the  routine. 

Additional  information  to  include  in  these  reports  is: 

1 .  Copy  texts  included . 

2.  Block/perform  range  structure  report. 
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Testcases  exercising  this  module 


4.1.4  Library  Contents  Enhancements 

The  library  contents  report  should  expand  into  more  detailed 
information  at  the  discretion  of  the  interactive  user.  For  instance 
the  undefined  entry  points  could  be  defined  as  stubs  by  an  interactive  user. 
This  report  also  needs  to  have  the  date  and  time  when  modules  were  read  in; 
this  information  could  probably  also  go  on  the  heading  of  hardcopy  source 
listings. 

4.1.5  Automatic  Restructuring 

GRC's  Fortran  Automatic  Verification  System  contains  a  function  for 
automatically  restructuring  FORTRAN  programs  to  eliminate  COTOs.  There  are 
several  problems  with  the  restructuring  procedure  as  it  now  exists: 

•  Automatic  restructuring  without  additional  human  input  produces  an 
equally  bad  program  without  GOTOs. 

•  Restructuring  a  program  causes  documentation  of  the  old  program's 
internal  logic  to  become  obsolete. 

•  Restructuring  large  programs  is  time-consuming  and  expensive. 

Drawing  on  the  experience  of  users  at  DMA  and  GRC,  we  believe  that  an 
improved,  cost-effective  restructuring  module  can  be  built,  to  add  COBOL 
restructuring  to  CAVS.  It  should  provide  these  services: 

•  Automatic  analysis  of  existing  program  structure. 

e  Easy-to-read  program  graph  reports .  These  would  show  how  to  break 
a  large  program  into  chunks  that  are  easily  understood  by  people 
and  easily  structured  by  computer. 

•  Error  and  diagnostic  reports.  Any  COBOL  constructs  that  render 
the  program  unstructurable  would  be  reported. 

e  Automatic  restructuring  of  COBOL  source  programs.  CAVS  would  be 
able  to  restructure  any  COBOL  dialect  it  could  recognise. 
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•  Automatic  chart  generation.  Documentation  (VTOCs  and/or  flow¬ 
charts)  for  newly  structured  programs  could  be  generated  mechani¬ 
cally.  Cost  of  documenting  these  new  versions  of  well-tested 
programs  would  be  reduced. 

4.1.6  Automatic  Documentation 

CAVS  is  designed  to  be  portable  across  computer  models  and  operating 
systems.  Its  automatic  documentation  modules  concentrate  on  the  portable 
portions  of  COBOL  programs.  But  information  about  nonportable  language 
constructs,  file  structures,  and  program  interfaces  can  also  be  important. 
During  conversion  from  one  computer  to  another  or  one  operating  system  to 
another,  knowledge  of  these  non-portable  system  characteristics  is  vital. 
Conversions  can  be  simplified  and  expedited  when  this  information  is  extracted 
and  presented  automatically. 

4.1.7  Management  Level  Functions 

The  AVS  can  be  made  intelligent  enough  to: 

e  Track  the  progress  of  modules  through  the  system. 

•  Report  their  status  to  users  and  management. 

•  Suggest  courses  of  action. 

•  Explain  what  happens  when  a  particular  course  is  selected. 

•  Search  and  manipulate  CAVS  report  output  in  ways  tailored  to  a 
specific  user-defined  problem. 

All  of  these  functions  should  be  available  to  on-line  users. 

HISTORY  is  a  proposed  system-wide  data  logging  function.  It  would 
record : 

•  When  modules  were  added  to  a  library. 

•  How  many  versions  of  a  module  had  been  added. 
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•  If  and  when  a  module  was  analyzed,  documented,  Instrumented,  or 
tested . 

•  Which  users  and  projects  were  actually  using  CAVS,  and  to  what 
degree . 

Status  displays  for  managers  and  programmers  would  reveal  the  current 
state  of  program  development  for  an  entire  project  or  for  a  single  program. 

How  the  tool  was  actually  used  could  then  be  more  accurately  determined.  Th 
AVS  should  collect  enough  data  about  its  own  behavior  to  guide  managers  and 
programmers  in  the  most  effective  use  of  the  tool. 

The  AVS  could  use  its  HISTORY  information  to  SUGGEST  courses  of  action 
to  on-line  users.  On-line  users  are  already  guided  through  a  work  cycle. 
Program  development  also  follows  a  predictable  cycle  of  coding,  analyzing, 
testing,  and  documentation.  The  AVS  could  look  at  a  module's  status  and 
propose  what  actions  should  be  done  next. 

SUGGEST  and  HISTORY  would  relieve  experienced  programmers  of  much  of  the 
bookkeeping  done  during  development  and  maintenance.  Inexperienced  pro¬ 
grammers  and  new  AVS  users  could  become  productive  more  quickly.  If  the 
suggestions  were  accepted,  the  AVS  could  begin  executing  the  function  immedi¬ 
ately  or  generate  a  job  to  execute  the  function  in  batch  mode. 

4.2  ENHANCED  USER  INTERFACE 

Enhancements  to  the  CAVS  user  interface  can  be  categorized  into 
two  classes: 

1.  Terminal-dependent  enhancements  -  such  as  horizontal/vertical 
scrolling,  and  multiple  windows.  These  techniques  are  best 
implemented  on  high-speed  video  terminals  and  could  substantially 
improve  the  usefulness  of  CAVS  on  those  terminals. 

2.  CAVS-dependent  enhancements  -  making  all  CAVS  reports  interactive 
in  a  sense  similar  to  the  structured  walkthrough.  These  tech¬ 
niques  would  apply  to  interactive  users  of  CAVS  at  any  kind  of 
terminal . 
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Note  chat  neither  of  these  approaches  excludes  the  other.  They  would  comple¬ 
ment  each  other  for  CAVS  users  at  high-speed  video  terminals. 


4.2.1  Scrolling 

Interactive  reports  are  generally  limited  to  one  screenful  at  a  time  - 
80  characters  by  24  lines.  One  way  to  overcome  this  size  limitation  is  to 
provide  scrolling  (horizontal  and  vertical)  within  the  tool  generating  the 
reports.  The  report  format  can  still  be  too  large  to  put  on  the  screen  all  at 
one  time,  but  the  interactive  user  can  'move'  the  screen  to  areas  of  interest. 
This  approach  is  limited  to  cursor-addressable  video  display  devices  operating 
at  a  fairly  high  baud  rate.  CAVS  currently  does  not  support  scrolling  in  any 
of  its  reports.  Instead  it  displays  one  screenful  of  information,  and  then 
prompts  the  user  to  end  the  report ,  view  the  next  screen  of  the  report ,  or 
display  a  related  report  (and  later  return  to  the  current  screen).  The  user 
cannot  back  up  and  view  the  previous  screen,  but  must  end  the  report  and  start 
from  the  beginning.  Vertical  scrolling  (on  suitable  high-speed  video  termi¬ 
nals)  would  be  better.  The  user  could  simply  scroll  forward  and  backward  as 
desired  in  the  current  screen.  Horizontal  scrolling  would  also  be  useful  for 
a  number  of  CAVS  reports.  For  instance,  the  indentation  of  source  code  often 
forces  long  source  lines  to  wrap  around,  reducing  the  number  of  source  lines 
on  the  video  screen.  Note  that  CAVS  could  still  generate  interactive  reports 
without  scrolling  on  low-speed  or  hard-copy  terminals. 


4.2.2  Multiple  Windows 

The  next  step  in  enhanced  user  interfaces  consists  of  multiple  windows 
(report  pages)  on  one  video  screen.  User  interfaces  employing  windows  which 
open,  expand,  contract,  scroll,  and  disappear  are  fast  becoming  accepted. 
Examples  of  systems  which  employ  this  concept  are  INTERLISP,  SMALLTALK,  the 
Apple  LISA  system,  VisiON,  and  a  number  of  other  new  microcomputer  software 
products.  The  basic  ideas  seem  to  be: 


1.  Screen  doesn't  automatically  scroll  up  because  it  never  overfills. 

2.  One  or  more  windows  may  be  active  at  a  time. 

3.  Windows  are  stacked  and  reappear  at  appropriate  times. 
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User  can  move  cursor  around  active  window  and  point  to  parts  of 
it. 


5.  Part  or  all  of  the  data  displayed  in  a  window  may  be  cutout  and 
then  pasted  into  something  else. 

6.  Windows  can  be  expanded  or  contracted  by  the  user. 

7.  Windows  can  be  scrolled  horizontallyor  vertically  by  the  user. 

8.  A  pointing  device  (mouse,  light  pen)  replaces  the  need  for  a 
keypad  and  greatly  reduces  the  number  of  keyboard  entries 
required. 

Scrolling  and  multiple  windows  are  techniques  which  have  been  evolved 
for  microcomputer  systems  (which  usually  have  a  high-speed  video  terminal  and 
a  low-speed  printer).  These  techniques  can  be  incorporated  into  CAVS  for 
enhancing  its  user  interface  on  selected  video  terminals,  without  degrading 
its  user  interface  on  other  terminals. 

4.2.3  Interactive  CAVS  Reports 

In  the  approach  currently  used  to  provide  interactive  CAVS  reports,  the 
user  directs  what  is  to  be  displayed  next,  and  the  natural  structure  of  the 
software  is  used  to  guide  the  user's  choices.  The  structured  walkthrough 
function  of  CAVS  is  currently  the  best  example,  but  other  reports  could  be 
handled  in  the  same  way.  A  significant  advantage  of  this  approach  is  that  it 
does  not  presume  a  sophisticated  video  terminal  -  the  structured  walkthrough 
can  be  done  from  a  hardcopy  terminal.  The  availability  of  a  video  terminal 
with  user-controllable  scrolling  and  windows  is  then  a  plus,  making  it 
possible  to  view  several  interactive  CAVS  reports  simultaneously. 

4.3  EXPANDED  WALKTHROUGH  CAPABILITY 

Use  of  CAVS  with  large  project  libraries  has  highlighted  the  following 
problems : 

1.  A  project  library  can  contain  a  wealth  of  information  about  a 

software  system.  Convenient  access  to  this  information,  in  the 
order  that  the  user  interactively  selects,  is  a  serious  problem. 
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2. 


The  project  library  will  usually  contain  information  about  a  large 
number  of  system-wide  names.  Not  allowing  the  CAVS  user  to  select 
a  specific  one  of  these  names  in  a  specific  program-ID  is  a 
deficiency. 

The  following  enhancements  to  make  CAVS  reports  more  . nteractive  would  help  to 
solve  these  problems . 

4.3.1  System  Walkthrough 

Calling  tree  reports  for  large  systems  quickly  get  out  of  hand, 
even  for  batch  reports.  An  interactive  approach  would  be  to  allow  the 
user  to  walkthrough  a  calling  tree,  and  to  ask  for  more  detailed  information 
about  that  part  of  the  tree  on  the  screen.  Information  should  be  made 
available  about  the  properties  of  formal  parameters,  their  usage,  and  the  text 
of  the  statements  they  occur  in.  The  same  kinds  of  information  should  also  be 
available  for  global  variables,  and  for  files  used  in  a  program-ID.  The 
information  currently  included  in  the  CAVS  module  documentation  report  should 
also  be  available  during  an  interactive  system  walkthrough.  The  user  should 
be  able  to  'expand'  a  program-ID  in  the  system  walkthrough  and  view  its 
internal  perform-range  structure  as  well  as  do  a  structured  walkthrough  within 
it. 


4.3.2  Source  Text  Report  Enhancements 

CAVS  displays  selected  source  text  for  the  interactive  user,  either 
during  a  structured  walkthrough  or  as  a  specified  statement  in  context  (five 
preceding  and  five  following  statements).  A  number  of  enhancements  to  these 
(and  related)  modes  of  text  display  will  increase  the  utility  of  CAVS  for 
interactive  users: 

1.  Horizontal  scrolling  to  overcome  the  line  wrap  problem. 

2.  Vertical  scrolling  for  more  continuity  in  displaying  source. 

3.  'Expanding'  symbols  by  name  to  give  one  of  several  possible 
reports . 
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4.  String  searching  during  the  structured  walkthrough  for  quick 
access  to  statements  of  Interest. 

T^e  following  'new'  source  text  reports  are  based  on  experience  In  using  the 
current  CAVS  source  text  reports: 

1.  STRUCTURED  WALKBACK  -  similar  to  structured  walkthrough  but  in  the 
opposite  direction.  This  report  would  be  especially  useful  for 
debugging  and  for  increasing  test  coverage.  While  tracing 
backwards  in  the  source  code,  the  report  would  provide  access  to 
all  information  in  the  project  library  about  global  variables, 
files,  and  entry  points.  To  enhance  the  usefulness  of  the 
structured  walkback  as  a  coverage  assistance  tool,  testing  history 
da^a  for  selected  testcases  could  be  displayed  during  the  walk- 
back.  Note  that  this  is  an  area  where  the  ability  to  display 
several  reports  on  the  screen  in  multiple  windows  would  make  an 
outstanding  contribution  to  the  utility  of  CAVS. 

2.  PATH  WALKTHROUGH /WALKBACK  -  similar  to  structured  walkthrough/ 
walkback,  but  well  suited  for  unstructured  code.  This  report  would 
allow  the  interactive  user  to  proceed  through  the  code  in  a 
branch-by-branch  analysis.  CAVS  would  maintain  a  history  of  the 
branches  taken  to  get  to  the  current  screen  (allowing  CAVS  to 
backtrack  for  the  user),  as  well  as  the  branches  not  followed. 
Library— wide  access  to  desired  information  and  the  ability  to 
'expand'  PERFORM  and  CALL  statements  as  in  the  structured  walk¬ 
through  would  be  provided. 

3.  TRACE  WALKTHROUGH/WALKBACK  -  similar  to  path  walkthrough/walkback 
but  with  branch  selection  controlled  by  reading  the  trace  file  for 
a  testcase.  User  controls  for  the  amount  of  source  to  display 
would  be  in  the  form  of  breakpoints,  or  user  selection  of 
PROGRAM-IDs  and  perform  ranges  to  display  at  the  terminal.  Note 
that  these  are  necessary  to  prevent  a  deluge  of  output  to  the 
terminal  and  to  control  the  speed  of  source  text  display. 
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4.  SYMBOLIC  WALKTHROUGH  -  an  extension  of  path  walkthroughs  using 
symbolic  execution  to  provide  the  current  values  for  symbols  upon 
user  request  at  any  point  in  the  walkthrough.  CAVS  would  essen¬ 
tially  act  as  the  bookkeeper  for  all  symbols  encountered  along  the 
current  walkthrough.  The  user  could  then  answer  questions  about 
the  current  value  of  individual  variables  without  having  to  back 
up  through  the  source  text. 

5.  PSEUDOCODE  WALKTHROUGH  -  pseudocode  descriptions  can  be  maintained 
on  the  same  project  library  as  the  actual  source.  It  could  be 
printed  in  hardcopy  reports  or  displayed  in  the  structured 
walkthrough  style.  Note  that  this  capability  could  also  be  used 
as  a  design  tool.  This  report  would  really  shine  as  a  documen¬ 
tation  and  maintenance  tool  with  a  multiple  window  format  because 
the  user  could  walkthrough  the  real  source  code  in  one  window  and 
the  psuedocode  in  another  window  (with  other  windows  available  for 
accessing  library  wide  information  at  the  same  time). 

6.  CONTEXT  REPORT  -  this  is  a  combination  of  the  structured  walk¬ 
through  and  cross-reference  report.  It  would  consist  of  displaying 
the  context  of  the  cross  reference  statements  (the  decision 
structure  which  leads  up  to  the  statements  in 

the  cross  reference  list).  Scrolling  with  this  display  is  also 
needed,  as  well  as  the  ability  to  expand  statements  (in  the  sense 
of  the  structured  walkthrough)  which  were  left  out. 

4.4  INTEGRATE  SOFTWARE  LIFE  CYCLE  TOOLS  IN  THE  AVS  CONTEXT 

Let's  briefly  forecast  software  life  cycle  technology  in  the  AVS 
environment  according  to  the  following  features: 

1.  FUNCTIONS  -  the  list  of  AVS  functions  can  be  expanded  to  include 
editing,  configuration  control,  management  reporting,  and  incre¬ 
mental  change  analysis. 

2 .  USER  INTERFACE  -  in  order  to  prevent  the  AVS  menu  system  (and 
user's  manual)  from  collapsing  under  its  own  weight,  a  set  of 
software  life  cycle  utilities  is  identified.  Each  operates  from  a 
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menu,  and  utilizes  an  extension  of  the  CAVS  project  library  as  a 
central  data  base. 


3.  PERFORMANCE  -  emphasis  Is  placed  on  maintaining  current  efficiency 
while  Increasing  functions  performed  and  ease  of  use. 

4.4.1  Editing 

CAVS  is  a  very  powerful  tool  for  reading  structured  source  code  at  a 
video  terminal,  but  it  does  not  include  any  way  to  modify  the  source  as  it  is 
being  read.  This  is  a  significant  limitation  of  an  otherwise  powerful  tool. 

We  do  not  suggest  incorporating  an  entire  text-editor  program  into  CAVS. 

Source  code  should  still  be  created  and  large  changes  made  with  the  user's 
favorite  editor.  But  small  changes  for  which  it  would  be  inconvenient  to 
check-out  a  whole  source  module  should  be  possible  directly  in  CAVS.  Also, 
some  source-code  editing  functions  may  be  found  especially  appropriate  for 
CAVS  (copying  large  blocks  of  existing  text  might  be  one). 

CAVS  Statement  Editing  Functions 

1.  Statement  insertion/deletion  -  note  that  this  is  not  the  same  as 
line  insertion/deletion. 

2.  String  search/replacement  -  the  string  search  function  would  be 
useful  during  source  text  reading  also. 

3.  Cutting/prefixing/appending/pasting  -  similar  to  word  processing 
cut/paste  buffers  but  more  natural  for  working  with  structured 
blocks  of  text. 

4.  Pending  statement(s)  -  to  note  that  a  particular  section  of  code 
is  not  yet  completed. 

5.  Cursor  functions  (video  mode)  -  inserting/deleting  characters  at 
the  cursor,  deleting  words. 

6.  Cursor  movement  -  end  of  statement,  beginning  of  statement,  scroll 
up,  scroll  down,  page  forward/backward. 

7.  Copying  -  copying  block  of  text  from  existing  routines. 


4.4.2  Configuration  Control  and  Management  Reportlni 

Configuration  control  and  management  is  one  of  several  directions  in 
which  to  steer  CAVS  evolution.  Configuration  control  consists  of: 

1.  Multiple  version  identification 

2.  Change  control 

3.  Status  reporting 

CAVS  emphasizes  the  importance  of  a  project  library  which  contains 
source  text,  as  well  as  interface  information  and  testing  history  information, 
so  that  meaningful  interactive  reports  can  be  generated.  Storing  the  same 
source  text  outside  CAVS  is  redundant  and  expensive,  especially  in  large 
software  systems  that  exist  in  several  versions.  CAVS  can  ease  the  configur¬ 
ation  problem  and  save  money  for  its  users  if  it  is  made  able  to  support 
multiple  versions.  Note  that  this  will  provide  not  only  multiple  versions  of 
source  text  but  also  multiple  versions  of  all  displays,  reports,  and  testing 
histories . 

The  following  is  a  suggested  list  of  configuration  control  functions: 

1.  DIFFERENCES  to  automatically  find  the  lines  that  are  different  in 
the  old  and  new  versions  of  a  COBOL  routine.  COBOL  source  text 
differences  (by  section  and  by  perform  range)  will  be  more  concise 
than  those  produced  by  general-purpose  difference  routines. 

2.  CHECK  OUT/IN  to  coordinate  changes  to  the  same  COBOL  routine. 

Allow  the  project  manager  to  decide  how  many  copies  of  the  same 
routine  can  be  checked  out  at  the  same  time.  Specific  job  control 
language  may  be  put  before  and  after  modules  as  they  are  checked 
out . 

3.  VERSIONS  to  produce  complete  source  text  listings  as  well  as  all 
project  library  reports  for  ALL  versions.  Given  an  earlier  and 
derived  version  name,  CAVS  can  produce  the  the  differences  between 
the  two  (in  terms  of  source  line  differences  as  well  as  project 
library  differences). 
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PROBLEM  REPORTS  for  multiple  versions  can  be  maintained  on  the 
project  library. 


Other  management  functions,  to  be  provided  by  the  host  environment  if 
possible  are: 

•  Management  reports. 

•  Interfaces  with  other  tools. 

•  Limitation  of  read/write  privileges  to  specific  areas  of  a  project 
library . 

•  Support  of  concurrent  updates  to  the  same  library. 

•  Merging  several  new  versions  of  the  same  routine. 

•  Storing  ob ject(relocatables)  ,  execute ( absolutes ) ,  job  control 
language,  test  data,  and  other  user-defined  data  which  is  not 
strictly  source  code. 

Menus  to  Support  Multiple  Versions 

The  Functions  menu  in  CAVS  could  be  modified  to  have  VERSION  SELECTION 
and  VERSION  DIFFERENCES  submenus.  In  the  following  example  they  are  items  14 
and  15. 


—FORTRAN  FUNCTIONS - 

1  -  READ  SOURCE 

2  -  ERRORS /WARNINGS 

3  -  PRECOMP ILE / IN STRMT 

4  -  MODULE  REPORTS 

5  -  SYMBOL  REPORTS 

6  -  REFORMAT 


- LIBRARY  FUNCTIONS - OTHER  FUNCTIONS - 

7  -  STRUCTURED  WALKTHROUGH  13-  DEFINE  REPORT  FORMAT 

8  -  SHOW  LIBRARY  CONTENTS  14-  VERSION  SELECTION 

9  -  SYSTEM  REPORTS  15-  VERSION  DIFFERENCES 

10  -  COVERAGE  ANALYSIS  16-  END  OF  CAVS  SESSION 

11  -  TRACE  FILE  REPORTS 

12  -  CHECK  OUT  SOURCE 


NEW  VERSION  -  (VAX  )  OLD  VERSION  -  (BASE  LINE  ) 


The  "new  version"  indicated  at  the  bottom  of  the  menu  indicates  the  version 
name  to  be  associated  with  any  new  or  modified  source  read  in  during  the 
current  session.  The  submenus  might  appear  as  follows: 


- VERSION  SELECTION - CURRENTLY - 

0  -  RETURN  TO  FUNCTION  MENU 

1  -  SELECT  OLD  VERSION  (WILDCARD  PROMPT)  BASELINE 

2  -  SPECIFY  A  NEW  VERSION  (NONE  SPECIFIED) 

3  -  VERSION  OVERVIEW 


- VERSION  DIFFERENCES 

0  -  RETURN  TO  FUNCTION  MENU 

1  -  SELECT  VERSION  A 

2  -  SELECT  VERSION  B 

3  -  TEXT  DIFFERENCES 

4  -  CALL  DIFFERENCES 

5  -  COMMON  BLOCK  DIFFERENCES 

6  -  COMDECK  DIFFERENCES 

7  -  FILE  DIFFERENCES 

8  -  TESTCASE  DIFFERENCES 


4.4.3  Incremental  Change  Analysis 

Incremental  change  analysis  means  not  having  to  reanalyze  each 
compilation  unit  that  has  changed,  but  only  each  modified  statement. 

1.  Incorporate  text  editing  features  into  CAVS. 

2.  Analyze  changed  lines  only,  rather  than  entire  PROGRAM-IDs  which 
have  changed. 


•CURRENTLY- 

VAX 

IBM 
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SPECIAL  COMMENTS 


This  section  summarises  the  knowledge  gained  during  the  CAVS  development 
(as  well  as  earlier  AVS  developments)  sponsored  by  RADC  and  DMA.  It  is 
intended  to  assist  designers  and  implementers  of  AVS  tools,  as  well  as  anyone 
modifying  or  enhancing  CAVS  (or  any  of  the  other  AVS  tools  discussed).  The 
table  below  summarizes  the  history  and  overall  features  of  the  AVS  tools 
developed: 


OVERVIEW 

When  was  the  AVS  completed  ? 


JAVS 


FAVS  .0 


FAVS .4 


1975 


1978 


CAVS 

1983 


I  1980 

What  was  the  approximate  cost?  |  $200k  |  $120k  |  $  70k  |  $500k  | 

- - — — - — — — — - - - — I— — - — - ( - — — — +— — — — f 

Number  of  initial  installations?  |  1  |  3  |  2  j  5  | 

Number  of  current  installations?  |  4  |  1-15  |  3-10  |  5  | 

Language  processed?  |  JOVIAL  I  FORTRAN  |  FORTRAN |  COBOL  ) 

_!J1  X . X  -  J 

Number  of  dialects  processed?  |  1  |  2  |  2  |  6  | 

Structured  extensions  processed?  |  none  |  DMATRAN  |  DMATRAN |  PSL  | 


Data  base  extensions  processed? 

J  none 

none  | 

none 

SYS-2000 

DMS-1100 

Ba tch/ inter active/both 

|  batch  | 

batch  | 

batch  | 

both  | 

Written  in 

j  JOVIAL  | 
|  J3  1 

DMATRAN  | 

I 

DMATRAN | 

DMATRAN 

Approximate  number  source  lines 

|  25k 

I  35k  | 

35k 

1  45k  | 

Real-world  use  of  FAVS.O  and  FAVS. 4  has  shown  that  AVS  tools  such  as 
these  are  valuable  aids  in  software  development.  The  major  hindrance  to  more 
widespread  use  of  these  tools  has  been  lack  of  coordinated  and  continuous 
maintenance  for  the  tools.  This  situation  should  improve  for  FAVS. 4  and  CAVS. 
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The  Defense  Mapping  Agency  (DMA)  is  currently  maintaining  FAVS.4,  plans 
to  maintain  CAVS,  and  plans  to  continue  the  maintenance  for  several  years. 

Maintenance  directly  relates  to  reliability,  the  most  important  feature 
for  these  tools  to  have.  The  next  most  important  features  are  what  functions 
they  perform  and  how  efficiently  they  perform  them.  When  AVS  tools  are  used 
in  large  software  development  projects,  it  is  essential  that  the  tools 
maintain  a  data  base  describing  the  total  software  system.  This  data  base 
will  naturally  be  large  and  complex.  Its  contents  are  crucial  in  determining 
the  functions  that  can  be  performed  and  what  it  costs  to  perform  them.  The 
next  table  briefly  summarizes  the  data  base  contents  of  each  AVS  tool: 

DATA  BASE  CONTENTS 

“  —  — — — — ————— —————— H 

Detailed  module  tables  | 

— — — ■ — — H 
Source  text  ) 

Testing  history  | 

- 1 

Copy  Text  source  | 

— —————— ———————— ——————— t 

Global  name  cross-reference  I 


The  chart  above  refers  to  the  contents  of  the  data  base  permanently 
maintained  by  the  tools.  All  of  the  tools  construct  detailed  module  tables 
for  the  source  code  that  is  read  in;  JAVS  and  FAVS.O  save  them  on  the  run- 
to-run  data  base.  FAVS.4  introduced  the  interface  library  concept,  extracting 
the  global  and  interface  information  from  the  detailed  module  tables  and 
saving  that  rather  than  the  much  larger  detailed  information.  A  simple 
analogy  may  help  to  illustrate  this  concept.  Reading  large  amounts  of  source 
text  and  extracting  global  and  interface  information  is  analogous  to  separa¬ 
ting  wheat  from  chaff .  You  end  up  with  a  big  pile  of  chaff  and  a  small  pile 
of  wheat.  Before  the  interface  library  concept,  the  AVS  tools  would  mix  the 
two  piles  together  at  the  end  of  a  run.  The  interface  library  concept  is 


simply  to  save  the  wheat  and  throw  the  chaff  away.  The  chart  below  Indicates 
the  major  Impact  that  this  approach  has  on  the  cost  of  using  the  tool  on  large 
software  developments. 


RESOURCE  USAGE  &  SIZE  CONSTRAINTS 

JAVS 

FAVS.O 

FAVS.4 

CAVS 

AVS  tlme/compilatlon  time  | 

10-100 

|  5-100 

|  1.5-3 

!  1-2  i 

Library  slze/source  size  j 

5  | 

1  io 

1  .3 

1  1.3  | 

Maximum  modules  per  library  | 

250 

|  250 

|no  limitjno  limit | 

Maximum  statements  per  library  j 

5k- 10k  | 

— 

! 

T 

1  O 

7? 

|  500k 

1 100k-200k 

The  tools  which  maintain  a  large  and  detailed  data  base  become  exponen¬ 
tially  more  expensive  to  run  on  larger  amounts  of  software.  "Tie  mean  time 
between  failures  on  the  host  computer  becomes  the  determining  factor  (as  well 
as  the  available  computer  budget)  In  how  large  a  library  can  be  built.  By 
introducing  the  interface  library  concept,  FAVS.4  greatly  increased  its 
usability  in  exactly  those  situations  where  It  is  of  most  value  -  large 
software  developments.  CAVS  extended  the  interface  library  concept  to  that  of 
the  project  library  which  contains  all  global  and  interface  information  as 
well  as  the  source  code  (but  not  detailed  module  tables)  and  testing  history. 
Retaining  the  source  text  in  CAVS  project  libraries  Is  essential  because  CAVS 
operates  In  Interactive  mode.  Interactive  users  want  to  see  their  source 
code,  not  the  statment  numbers  that  refer  to  the  source  code. 

The  next  most  important  feature  of  the  AVS  tools  is  their  user  Inter¬ 
face:  how  easy  are  they  to  use?  The  chart  below  summarizes  the  batch  user 
interfaces  of  the  tools. 


BATCH 

COMMAND  PROPERTIES  JAVS 

FAVS.O 

FAVS.4 

CAVS 

Report 

oriented/process  oriented  |  process | 

report 

I 

report 

|  report  | 

Report 

index  generated  by  tool?  |  no  | 

ye  8 

1 

H- 

yes 

1  yes  | 

-  f  -f 
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The  essential  lesson  learned  here  is  that  batch  users  should  tell  the  tool 
what  they  want  (In  terms  of  reports),  not  the  process  or  sequence  of  steps 
required  to  produce  the  reports. 


CAVS  Is  the  only  one  of  the  four  AVS  tools  that  supports  Interactive 
use.  CAVS  provides  batch  commands  for  batch  usage,  and  menus/help  screens  for 
Interactive  use.  CAVS  menu  conmands  are  also  available  for  expert  CAVS  users. 
The  chart  below  summarizes  the  interactive  interface  properties. 


INTERACTIVE  INTERFACE  PROPERTIES 

JAVS 

FAVS  .0 

FAVS  .4 

CAVS 

Menus /commands 

I 

none 

]  none 

|  none  | 

both  | 

Number  of  menus 

1 

0 

1  o 

1  o  | 

35  | 

Number  of  help  screens 

1 

none 

|  none 

|  none  | 

200  | 

Name  selection( full  name/wildcard) 

full 

|  full 

1  full  1 

both  | 

The  functions  performed  by  the  AVS  tools  are  best  indicated  by  the 
reports  which  they  produce  and  the  analysis  they  support.  Nine  types  of 
reports,  features,  and  analysis  are  distinguished: 


REPORT/FEATURE/ANALYSIS 

1 .  Library  contents  reports 

2.  Source  listing  features 

3.  Detailed  module  reports 

4.  System  documentation 

5.  Error/warning  functions 

6.  Precompilation  functions 

7.  Dynamic  analysis  functions 

8.  Reformatting  functions 

9.  Selective  report  generation 


DESCRIPTION 

Reports  which  describe  the  permanent 
data  base 

Additional  features  of  source  code 
listings 

Reports  about  individual  compilation 
units 

Reports  about  the  whole  software  system 

Additional  static  analysis  features 

Source  code  transformations 

Analysis  of  run-time  behavior 

Readability/maintainability  transfor¬ 
mations 

Reports  about  selected  individual  names 
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The  table  below  summarizes  the  total  number  of  reports/features/functions  for 
each  AVS  tool .  The  growth  In  the  number  of  functions  supported  is  evident  by 
comparing  JAVS  (the  first  AVS  tool)  to  CAVS  (the  most  current  tool).  JAVS  had 
22  total  reports/features/functions,  while  CAVS  has  75.  Each  of  the  nine 
categories  is  elaborated  in  the  charts  which  follow. 


REPORTS /FEATURES /FUNCTIONS 

JAVS 

FAVS  .0 

FAVS  .4 

CAVS 

Total  library  reports  | 

2  | 

2 

1  2 

1 

8 

Additional  listing  features  j 

1  | 

1 

1  2 

1 

9 

Total  detailed  reports  | 

4  | 

6 

|  7 

1 

13 

Total  system  reports  | 

4  | 

7 

1  8 

1 

17 

Total  error/waming  features  j 

0  | 

4 

1  4 

1 

7 

Total  precompilation  functions  | 

4  | 

1 

|  1 

1 

6 

Total  dynamic  analysis  functions  | 

4  | 

2 

1  2 

1 

6 

Total  reformatting  functions  j 

1  | 

1 

|  1 

! 

1 

Total  name  selections  | 

2  I 

1 

|  1 

1 

8 

Total  reports/features/functions |  22  |  25  |  28  |  75 
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LIBRARY  CONTENTS  REPORTS 


JAVS 


FAVS.O 


FAVS.4 


CAVS 


Modules/entry  points 

Common  s / comp  oo 1 s 

Copy  text /includes 

Entry  points  defined/not  called 

Entry  points  called/not  defined 

Testcases 

Files 

Current  modules 

Total  library  reports 


1  yes 

yes 

1  no  1 

yes 

|  no  ! 

yes 

1  no 

yes 

1  no  ! 

yes 

SOURCE 

LISTING  FUNCTIONS 

JAVS 

FAVS.O 

FAVS. 

4  CAVS 

Indent 

source  | 

yes 

i 

yes 

1  yes 

1  yes 

I 

Reconstructed/Original  source  j 

re  con 

i 

recon 

orig 

1  orig 

1 

Internal  procedure  XREF  | 

no 

i 

no 

no 

1  yes 

I 

List  a 

range  of  statements  ] 

no 

i 

no 

no 

1  yes 

1 

List  a 

depth  of  statements  | 

no 

t 

no 

no 

1  yes 

1 

Expand 

internal  procedure  calls  | 

no 

i 

no 

no 

1  yes 

1 

Expand 

external  procedure  calls  | 

no 

i 

no 

IbII 

1 

Omit/expand  nested  code  | 

no 

I 

no 

no 

i  yes 

1 

DETAILED  DOCUMENTATION  REPORTS 

JAVS 

FAVS .0 

FAVS. 

4 

CAVS 

Picture  report 

1 

yes 

no 

1 

yes 

I 

yes 

I 

Statement  profile  report 

1 

no 

yes 

1 

yes 

i 

ye  8 

1 

Reaching  set  report 

1 

yes 

yes 

1 

yes 

1 

yes 

1 

Symbol  properties  report 

1 

no 

yes 

1 

yes 

1 

yes 

1 

Symbol  Xref  report 

1 

yes 

yes 

1 

yes 

i 

yes 

1 

Symbol  source  report 

1 

no 

no 

I 

no 

i 

yes 

t 

Labels  Xref  report 

1 

no 

no 

i 

no 

i 

yes 

I 

Labels  source  report 

j 

no 

no 

i 

no 

i 

yes 

1 

Constants  Xref  report 

1 

no 

no 

j 

no 

j 

yes 

1 

Constants  Source  report 

1 

no 

no 

i 

no 

i 

ye  8 

1 

Externals  Xref  report 

i 

no 

yes 

i 

yes 

i 

yes 

i 

Externals  source  report 

i 

yes 

yes 

i 

yes 

i 

yes 

1 

Module  Documentation  report 

j 

no 

no 

i 

no 

i 

yes 

1 

Total  detailed  reports) 

6 

i 

7 

i 

13 

1 

p 


SYSTEM  DOCUMENTATION  REPORTS 
Symbol  Xref 


JAVS 

yes 


FAVS.O 


no 


FAVS.4 
yes 


CAVS 

yes 


Common/ Comp ool  Summary 
Common/ Comp ool  Matrix 
Common/ Comp ool  Xref 
Common /Compool  Source 
Copy  Text  Summary 
Copy  Text  Matrix 
Copy  Text  Xref 
Copy  Text  Source 
File  Summary 


no 

no 

no 

no 

NA 


yes 

yes 

yes 

no 

no 


ye  8 
yes 
yes 

no 

no 


yes 
yes 
yes 
ye  8 


NA 

NA 

NA 

no 


no 


no 


no 


no 


ye  8 
yes 


no 


no 


no 


File  Matrix 
File  Xref 
File  Source 


no 


no 


no 


no 


no 


no 


yes 


Entry  Point  Summary 
Entry  Point  Bands 


yes 

yes 


yes 

yes 


Entry  Point  Tree 
Entry  Point  Xref 
Entry  Point  Source 


yes 


no 


no 


yes 

no 


no 

yes 

yes 

yes 

no 

yes 

no 


yes 

yes 

yes 

yes 

yes 

yes 

yes 

yes 


no 


yes 

yes 


Total  system  reports 


8 


17 
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ERROR/WARNING  FUNCTIONS 


Call  Checking 


Graph  Checking 


Mode/Picture  Checking 


Set/Use  Checking 


Data  Flow  Checking 


JAVS  FAVS.O 


FAVS.4 


Access  to  source  of  called  routines  no 


Access  to  symbol  reports 


Total  error/warning  features |  0 


PRECOMPILATION  FUNCTIONS 


FAVS.O  FAVS.4 


Structured  Dialect  Precompilation |  no 


Control  Flow  Instrumentation 


Assertion  Instrumentation 


Trace  Instrumentation 


Timing  Instrumentation 
File  I/O  Instrumentation 


Check-out  source  code 


- + 


Total  precompilation  functions |  4 


DYNAMIC  ANALYSIS  FUNCTIONS 
Control  flow  summary 
Control  flow  counts 
Control  flow  source 
Control  flow  history 
Abort  trace 
Timing 
File  I/O 


JAVS 

yes 

yes 

yes 


no 


no 


yes 

no 


FAVS.O 

yes 

yes 

no 

no 

no 


no 


FAVS.4 

yes 

yes 


1 — 

1 

1 — 

no 

1 

- f* 

i 

no 

1 

1  no  | 

1 

no 

1 

—4* 

1 

no 

1 

— — f- 

1 

2 

1 

CAVS 

yes 

no 

yes 

yes 

yes 

yes 

yes 


Total  dynamic  analysis  functions 


REFORMATTING  FUNCTIONS 

JAVS 

FAVS.O 

_1 _ 

FAVS.4 

CAVS 

Reformat  source  code 

1  yes 

j  no 

__i _  _ 

r  no  t 

—1 _  _ l _ 

yes 

Restructure  source  code 

|  no 

1  yes 

1 -  1 - 

1  yes  | 

no 

Total  reformatting  functions  |  1  j  I  |  1  |  1 
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SELECTIVE  REPORT  GENERATION  JAVS 

I  yes 
I  yes 


By  Module  name 
By  Entry  Point  name 
By  Symbol  name 
By  Label  name 


no 


no 


By  Constant  name 

- H - 

1 

no 

T 

no 

By  Common/ Compool  name 

1 

no 

i 

no 

By  Copy  text  name 

1 

no 

i 

no 

By  File  name 

1 

no 

i 

no 

By  Testcase  name 

1 

no 

i 

no 

' 

Total  name 

selections | 

2 

i 

i 

FAVS  *0 
yes 
no 

no 

no 


FAVS. 4 
yes 
no 

no 

no 

no 


no 


no 


no 


CAVS 

yes 

yes 

yes 

yes 

yes 

yes 

yes 

yes 

yes 


8 
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MISSION 
of 

Rome  Air  Development  Center 

RA VC  plant)  and.  executes  research,  development,  te&t  and 
selected  acquisition  programs  in  support  of  Command,  Control 
Communications  and  Intelligence  (C3I)  activities.  Technical 
and  engineering  support  within  areas  of  technical  competence 
is  provided  to  ESP  Program  Offices  (POs)  and  other  ESP 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur¬ 
veillance  of  ground  and  aerospace  objects,  intelligence  data 
collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility . 
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